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IP DATA TRZ^SMISSION NETWORK USING A ROUTE SELECTION BASED ON 

LEVEL 4/5 PROTOCOL INFORMATION 

Technical field 

The invention relates to IP data transmission networks wherein 
5 the route is determined in each router of the data path by using 
a combination of metrics, and relates in particular to an IP data 
transmission network that selects routes based on level 4/5 
information. 



Background 

I§ When data packets are transmitted from a source workstation to a 
destination workstation over an IP data transmission network, the 

p packets are routed from node to node in the network by a routing 
mechanism implemented by a router in each node of the data path. 

Each IP datagram received by a node and which specifies a 
15 destination address other than the local node address is subject 
to the IP routing algorithm by the router of the node which 
selects the next node for the datagram. For this, the router uses 
a routing table which contains information about the other 
routers of its own network and about IP networks to which its own 
20 network is attached. 

The routing mechanism enables the optimal routing path to be 
determined. Such a path determination is based on a variety of 
metrics or a combination of metrics, such metrics being values 
resulting from algorithmic computations on a particular variable 
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or values directly input by the router administrator . The 
comparison of the metrics allows the router to determine the 
optimal routes and therefore to establish the routing table. 

Many different metrics have been used in routing algorithms. 
Sophisticated routing algorithms can base the route selection on 
multiple metrics, combining them in a manner resulting in a 
single metric. For this, several metrics may be used. Path length 
is the most common metric. Some routing protocols allow the 
network administrator to assign arbitrary costs to each network 
link. In this case, the path length is the sum of the costs 
associated with each link traversed. Another important metric to 
be used is the communication cost, insofar as some companies may 
not care about performance whereas they care about operating 
expenditures. Other metrics may also be used, such as the 
reliability (usually described in terms of bit error rate) of 
each network link, delay (the time required to move a packet from 
a source to a destination) , bandwidth (available traffic capacity 
of a link), or load (the degree to which a network resource such 
a router is busy) . 

All the information used by the routing protocol to determine the 
metrics comes from the lowest three layers of the protocol stack. 
It is important to note that in the internet protocols as well as 
in the Open System Interconnect (OSI) model, the layer which 
defines the packet delivery, including routing, is the third 
layer. Put conversely, the upper layers of the protocol stack, 
which constitute the layer 4/5 in the network procedures, are not 
used to determine metrics and therefore to build the routing 
table. These upper layers define the application such as the 
Transmission Control Protocol (TCP) or the User Datagram Protocol 
(UDP) . 
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There have been several attemps to use the level 4/5 information 
in the routing algorithm. All these approaches were based on the 
assumption that the source and destination workstations provide 
information to the routers and support a specific protocol to set 
the inputs. These attempts, which focused on using level 4/5 
information (for the TCP/IP model as well as for the OSI 
model), have been abandoned, as the did not result in stable and 
durable implementations. One such attempt was implemented in 
OSPF, using the configuration parameters called Type of Service 
(TOS) . This mechanism requires the application to set the TOS 
field in all IP data generated by the source workstation. 
Unfortunately, the support of TOS in routing requires 
modifications to the application. Today, no application is 
implemented in such a way. Therefore, the use of the TOS field 
has been dropped in recent OSPF implementations according to the 
latest RFC recommendations. Some other attempts use a priority 
queue in the routers : the router tries to look at some field 
significant of level 4/5 application layer when receiving the IP 
data packets, in order to set some priority in an input/output 
buffer. Such a mechanism acts on the data transmission speed, but 
does not modify the routing path. 

STJuranairy of the invention 

Accordingly, the main object of the present invention is to 
provide a route selection in the routing algorithm of an IP data 
transmission network which depends upon the type of application 
used in a communication between a source workstation and a 
destination workstation. 

Another object of the present invention is to select a routing 
path in OSPF routing protocol according to the TCP or UDP port 
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required in each router of a transmission path in an IP data 
transmission network. 

The invention relates therefore to a data transmission system for 
transmitting packets of data from a source workstation to a 
destination workstation. Packets of data are transmitted over a 
communication network such as an IP network between an ingress 
node connected to the source workstation and an egress node 
connected to the destination workstation. Each router within the 
intermediary nodes along the data path from the ingress node to 
the egress node determines the best route in a routing table 
defined by the contents of a field contained in each packet of 
data being received. To accomplish this, the router at the 
ingress node comprises a configuration table which associates the 
contents of the field with information carried by a protocol 
layer above the IP level, generally the 4/5 level such as TCP or 
UDP, In one embodiment of the invention, the field employed is 
the Type-of-Service (TOS) field. 

Brief description of the drawings 

The above and other objects, features and advantages of the 
invention will be better understood by reading the following 
description of the invention in conjunction with the accompanying 
drawings wherein : 

-Fig. 1 is a block-diagram representing a data transmission 

network wherein the invention may be implemented. 

-Fig. 2 is a schematic representation of an IP datagram with 

the various fields of the IP header. 

-Fig. 3 shows the contents of the service type field of the IP 
datagram including the TOS bits. 

-Fig, 4 is a schematic representation of the IP datagram 
showing the TCP/UDP header after the IP header. 
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-Fig. 5 is a flow-chart of the operation of an ingress node 
according to the invention, 

-Fig. 5 is a schematic representation of configuration table 
used in the data transmission system according to the 
invention . 

-Fig, 7 is a block-diagram representing the router of the 
ingress node according to the invention. 

Detailed description of the invention 

A data communication system that is suitable for accomodating the 
present invention is shown in Fig, 1. As a source workstation 10 
attached to a LAN 12 may access an IP network 14 through an 
ingress node 16; in order to transmit packets of data to a 
destination workstation 18 that is connected to the network 14 by 
an egress node 20, 

The optimal route, which is found by computing a combination of 
metrics, is determined in the ingress node 20 according to the 
level 4/5 information as described below. With one application, 
such a route could be through a first intermediary node 22, 
whereas with a different application the optimal route could be 
through a second intermediary node 24, 

For example, suppose that the first application is a 
Voice-over-Internet-Protocol session (VoIP) requiring low delay, 
but not requiring a large bandwidth, and suppose that the second 
application is a data batch transfer using File Transfer Protocol 
(FTP) , without any particular delay requirement but requiring 
large throughput. Further, suppose that the delay through the 
first intermediate node 22 is less than the delay though the 
second intermediate node 24 but, the overall bandwidth on the 
former route is limited. Also, suppose that the delay through the 
second intermediate node 24 is greater but a lot of free 



FR920000008US1 



5 



r 



bandwidth is available on this second route. Because of the 
shorter delay on the route through the first intermediate node 
22; both sessions, voice and data, would be established on this 
route when using legacy OSPF, whereas the invention based on the 
5 4/5 level information enables two optimal routes to be 
established, thereby improving the load balancing between all 
routes in the network. 

As illustrated in Fig. 2, an IP datagram data includes an IP 
header 24 containing the information necessary to send the packet 
10 in correct form over the route, such as the source IP address or 
the IP destination address, and the IP data field 26. The header 
24 includes a service type field 28, which is illustrated in Fig. 
7q 3. Such a service type field includes two bits for precedence (a 
m measure of the priority of the datagram) , a MBZ bit (must be 
W zero) reserved for future use, and four Type Of Service bits 
;r (bits 3-6) , which characterize some parameters of the application 
m such as the propagation time, the throughput, and the 
reliability. 

j:: As shown in Fig. 4, the IP data field 26 of an IP datagram 
If includes a header TCP/UDP and data. Note that in both TCP and 
^ UDP protocols and other 4/5 level protocols, the header includes 

a field containing the source port number and a field containing 

the destination port number. 

Fig. 5 shows the operation of the ingress node 16 (see Fig. 1) , 
25 when a frame is received (step 30) . First, the protocol 
identification is made by extracting (step 32) the associated 
field in the IP header 24 of the IP datagram (see Fig. 2) . The 
source and/or destination port number is also extracted (step 34) 
from the 4/5 level header. Then, there is a lookup of a 
30 configuration table represented in Fig. 6 (step 36) . Such a 
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configuration table provides the TOS field corresponding to a 
given protocol and a given port number (source and/or 
destination) . It must be noted that, insofar as there can be 
numerous port numbers for each protocol being identified, such a 
table may not contain all possible cases. 

The lookup of the configuration table determines whether an entry 
of the table is associated with the protocol being identified 
(step 38) . If so, it is then determined whether the port number 
extracted from the 4/5 level header is identified in the 
configuration table (step 40). If the port number is found, the 
TOS bits in the IP datagram are replaced (step 42) by the bits 
which are found in the configuration table. It must be noted that 
the TOS bits are previously all zeros corresponding to the 
default route. Finally, the routing task is achieved by the OSPF 
protocol or an equivalent protocol (step 44) before transmitting 
the frame over the network. 

When the protocol being identified in the IP datagram does not 
correspond to any entry in the configuration table, or when the 
port number for this protocol is not found in the configuration 
table corresponding to the port number identified in the 4/5 
level header, the TOS bits are set to zero or not changed if they 
were already set to zero (step 46) . Then, the OSPF (or equivalent 
protocol) routing task is achieved by the router (step 44) . Note 
that, in the latter case, the ''all zeros" TOS defines only the 
default route , 

As illustrated in Fig. 7, the router of ingress node 20 (see Fig. 
1) includes a protocol processing unit 50 which identifies the 
protocol associated with the application in the received frame. 
Thus, such a protocol can be UDP plus Real Time Protocol (RTP) 
for the voice flow, or TCP plus FTP for the data flow. Note that 
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the protocol processing unit 50 also looks for the port number 
associated with the protocol in the frame header as already 
mentioned. 

When the protocol and the port number are identified by the 
protocol processing unit 50, the frame-together with this 
information is transmitted to a forwarding processing unit 52 , 
The protocol and the port number enable the forwarding processing 
unit 52 to look in the configuration table 54 for determining the 
value of TOS bits corresponding to this protocol and this port 
number. Then, the forwarding processing unit 52 replaces in the 
frame the previous TOS bits (generally zero bits) by the value 
determined in the configuration table 54, and stores the frame 
into a frame buffer 56. The TOS value also enables the forwarding 
processing unit 52 to select an appropriate routing table 
identifying the route to be used, for example a routing table 58 
containing routing information for the UDP protocol, or a routing 
table 60 containing routing information for the TCP protocol. 
Then, the forwarding processing unit 52 utilizes this routing 
information to select an output queue for transmitting the frame 
over the network. In the previous example, the voice frame using 
UDP will have routing information that will enable the transfer 
of the voice frame from the frame buffer 56 to an output queue 62 
for transmission to the first intermediate node 22, whereas the 
data frame using TCP will have routing information that will 
enable the transfer of the data frame from the frame buffer 5 6 to 
an output queue 64 for transmission to the second intermediate 
node 24. 

The routers of all the other nodes of the route such as the first 
and second intermediate nodes 22 and 2 4 include the same 
components except the configuration table, since these nodes have 
no need to determine and to change the value of the TOS field in 
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the frame. In the same way as in the ingress node, the TOS value 
enables each router to select the appropriate routing table in 
order to know the routing information and to transmit the frame 
to the next node of the route . 
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